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REMARKS 

Claims 1-32 were pending in the application at the time the present Office Action 
was mailed. Claims 1 and 6-10 are amended by this response. Claim 5 is canceled by 
this response and no claims are added. Accordingly, claims 1-4 and 6-32 remain pending. 

The status of the claims in light of the Office Action is as follows: 

1. Claims 1-8, 10-14, 16-22, and 24-27 were rejected under 35 U.S.C. § 103(a) 
as being unpatentable over U.S. Patent No. 6,487,584 ("Bunney") in view of "All quiet on 
the NetWare Front" ("Runyan"); 

2. Claims 9, 15, 23, and 28 were rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Bunney in view of Runyan and further in view of U.S. Patent 
No. 6,301,609 and 6,480,593; and 

3. Claims 29-32 were rejected under 35 U.S.C. § 102(e) as being unpatentable 
over U.S. Patent No. 6,760,754 ("Isaacs"). 

As a preliminary matter, applicants note that Isaacs was disqualified by applicants' 
response of August 4, 2005 as a reference against claims that were pending. As 
suggested by the Examiner during a telephone conference to discuss this point on 
October 31, 2005, applicants treat claims 29-32 in these remarks as if they were rejected 
under 35 U.S.C. § 103(a) over Bunney in view of Runyan. 

Applicants have amended claims 1, 9 and 10 to more particularly claim their 
invention. Applicants have amended claims 6-8 to correct typographical errors and 
improve readability. 

Bunney Reference 

The following description of Bunney was provided by applicants in their response of 
November 22, 2004. 
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Bunney describes a "notification server that operates in an environment where a 
user has multiple identities. For example, a user may have the identities of 
"George@compu.xxx.com," "Superman@sports.xxx.com," and "Max@game.xxx.com." 
Bunney's technique allows a user who is logged on using one identity to receive 
notifications of messages sent to one of their other identities. For example, if a user is 
logged on to "George@compu.xxx.com" and a message is sent to 
"Superman@sports.xxx.com," the user is notified of the message via their 
"George@compu.xxx.com" identity. The user can then switch to their other identity to view 
the message. Bunney describes that a user when working in one identity can indicate that 
they do not want to be receive notifications of messages sent to certain other of their 
identities. For example, a user logged on to a work-related identity may not want to 
receive notifications of messages sent their recreation-related identity. Bunney describes 
that a server tracks the identities for each user and the "current" identity to which the user 
is currently logged on so that the notifications can be sent to the current identity as 
appropriate. (Bunney, 8:22-9:32.) 

Bunney also describes a "session manager" that tracks the current state of a user 
such as available, away, invisible, or busy. The state defines the availability of the user to 
receive notifications from other users. For example, when in the available state, a user will 
receive notifications from any user, and when in the busy state, the user will not receive 
any such notifications. 

Applicants' Technology 

Applicants' technology, in contrast, is directed to maintaining the master status of a 
user who may be logged on via multiple clients, such as in an instant messaging ("IM") 
environment. For example, a user may log onto the IM environment with an identity (e.g., 
user@xxx.com) using a desktop computer and again with the same identity using a 
personal digital assistant so that the user is logged on through both clients at the same 
time using the same identity. If the user then logs off from the personal digital assistant, 
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applicants' technology determines a master status, which in this simple case may still be 
online. Since the statuses can be at various levels of detail, such as busy, idle, out to 
lunch, back soon, and on the phone, and may be conflicting, such as busy and idle, the 
determination of the master status of a user may be more complex. For example, if one 
client reports a status of busy and then another client reports as status of idle, the 
determination may be to ignore the idle status and leave the master status as busy, since 
the user may be idle at one client but busy at another. 

Analysis 

Bunney neither teaches nor suggests that a master status is maintained for a user 
based on statuses reported by multiple clients to which the user is logged on. The Office 
Action appears to equate the master status with Bunney's table that stores information 
corresponding to the list of identities associated with each user. (Office Action, page 3.) 
According to Bunney's Figure 3 and its related description at Bunney, 8:45-10:5, Bunney's 
table merely stores a list of users and their associated identities. According to the Office 
Action, "Bunney discloses the server checking the table to see which address to send a 
notification to" and cites Bunney at 9:1-20. (Office Action, page 3.) As is described in the 
cited section, the table enables Bunney's technique to determine that a notification can be 
delivered to a user even when the user is logged on using an identity other than the 
identity indicated by the notification. Thus, for example, even when "George X. has logged 
in using the address , George@compu.xxx.com' an E-mail message sent for example to the 
address , Superman@sport.xxx.com' will cause a notification to be sent to George X." 
(Bunney, 9:12-16.) As is described above, applicants' technology determines a master 
status for a user based on the user's status on multiple clients. This master status is 
provided to other subscribing users who desire this status information. Thus, while 
Bunney's technique employs the table to determine whether a notification intended for a 
particular identity associated with a user should be sent even when the indicated identity is 
not logged on but another identity associated with the same user is indicated to be logged 
on, applicants' master status is reflected to other users, as is recited by at least claim 1 . 
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The Office Action further points to Bunney at 7:5-30 and 9:25-35 as teaching or 
suggesting that a master status is stored on a server or provided to other electronic 
messaging users. Bunney's Session Manager's session state is described at 7:5-30. 
According to that section, a user can control whether or not the user will receive 
notifications and what status for the user is provided to other users. "The user can 
associate the 'Do no disturb' sign for a limited number of his identities. For example, when 
logged-in with the address , George@compu.xxx.com'Q, the user can select to not receive 
any message or notification addressed to his other address 'Superman@sport.xxx.com'. 
Therefore he will not be disturbed by other users seeking for sport orientated users when 
working professionally on his terminal." (Bunney, 9:25-32, sic). Thus, Bunney's Session 
Manager does not determine a master status for a user based on the user's status on 
multiple clients. 

The Office Action does not indicate that the master status is taught or suggested by 
any of the other applied references and applicants are unable to find such a teaching or 
suggestion in the other applied references. 

Each of the independent claims recites employing a master status for a user that is 
determined from status information for the user on multiple clients. As an example, claim 1 
recites "determine the master status of the electronic messaging user identifed by the user 
identification who is logged on via both the first client computer system and the second 
client computer system." Claim 10 recites "updating in the master view at the server the 
consolidated presence information for the electronic messaging user identified by the user 
identification based on an evaluation of the status update and each view status." Claim 19 
recites "for each subsequent status change received from one of the multiple clients at the 
server, updating the master status." Claim 27 recites "consolidate at the server presence 
information for the user based on an evaluation of each view status... [and] update at the 
server the consolidated presence information." Claim 29 recites "generating the master 
presence status representing a current presence status of the user based on the received 
client presence statuses reported by the multiple clients." Because these features are 
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neither taught nor suggested by the applied references, the applicants' independent claims 
cannot be rejected under either 35 U.S.C. § 102(b) or 35 U.S.C. § 103(a). Because the 
dependent claims import the limitations from the claims on which they depend, they also 
cannot be rejected under 35 U.S.C. § 102(b) or 35 U.S.C. § 103(a). Moreover, the claims 
recite a novel combination of elements that is neither taught nor suggested by the applied 



Based on the above amendments and remarks, applicants respectfully request 
reconsideration of this application and its early allowance. If the Examiner has any 
questions or believes a telephone conference would expedite prosecution of this 
application, the Examiner is encouraged to call the undersigned at (206) 359-6478. 



references. 




Respectfully submitted, 




Registration No.: 55,592 
PERKINS COIE LLP 
P.O. Box 1247 

Seattle, Washington 981 1 1 -1 247 
(206) 359-8000 
(206) 359-7198 (Fax) 
Attorneys for Applicant 
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